Service Oriented architecture, REST API's, seems to be in sharp contrast with Event Driven Architecture. It has been believed that EDA's are better suited for loosely coupled architectures and scalability. No more waiting on the response, just forget-and-fire. However, fully adopting an Event-Driven architecture does not solve all the problems.
A restricting feature for flexibility and scalability of a service oriented architecture is the gearing towards client-driven, request-response interactions. A client calls a service via an API or gRPC call and has to wait on a response of the service before moving on. Event-Driven architectures however are connectionless. Their distribution is about fire-and-forget. On the other hand it only starts to respond to things when a relevant event has been published. It reduces the physical and temporary coupling between request-response client and services.
Jerry Mathew listed the differences between the two patterns in SOA vs. EDA: Is Not Life Simply a Series of Events? | Confluent.
| SOA | EDA | |
|---|---|---|
| Pull vs. Reactive | Client makes a request of a service and expects a response. It’s great for persisted, static data, but gets a little hard when data keeps changing. You have to poll to detect changes. | Subscription model pushes events to consumers. |
| Coupling | Client has to know details of the API and its location at runtime. | Producers have no knowledge of consumer which will ultimately receive the event. There is still some minimal coupling in terms names of queues/topics and event formats. |
| Service Availability | A service must be available at the time a request is made by a client even if you are doing an asynchronous response handling. | Events do not require a reply and are inherently asynchronous. Events can be persisted for future consumption. With a highly fault-tolerant broker, the event producer does not need to know whether the consumers are available. Thus, we achieve higher resilience to network and compute failure, and this allows event producers to avoid blocking. |
| Process Modification and Extension | Processing logic is a request-response API that is hardwired into a service endpoint (with or without service discovery). If the logic needs to change or be extended, or if new logic needs to be introduced, the definition (not contract) of the service must be updated. This introduces change management and regression risk. | Additional event producers and consumers can be added to a system without any explicit process definition. |
| Consistency Between Process Interaction and Internal State Management | State changes are managed based on requests. For example, a request to “withdraw money” mutates the state of an account. The distinct processes of a request, a change in state and its persistence in case of failure must be tied together transactionally. This often leads users to deploy expensive distributed transaction protocols like eXtended architecture (XA). | EDA provides better support for consistency between process interaction and persisted internal state transitions. This is done through the event sourcing pattern, where the communication protocol (the event) is also the persistence mechanism (the event log). The current state of a system can be built or rebuilt from the log of events. |
| Retaining the Exact State Transitions That Customers or Services Perform | In SOAs, data is typically “mutated in place” in a database. This is a lossy process where each state change loses the information about the state changes that happened previously. | EDAs are event sourced, meaning every state change is captured, providing a truthful journal of the exact state changes that every customer or every service made over time. This journal lets operators rewind time to view or replay previous events exactly as they happened. It is also important for analytics that review customer (or system) behaviour to derive insight. |
| Streaming Analytics | SOA is incapable of deriving analytics of data in flight. This requires the ability to detect a pattern from multiple state changes both temporally and spatially. | EDA is fully capable of detecting patterns across multiple event sources over many different types of time windows. Also, deriving analytics of data in flight is a means of continuous intelligence. |
| The Timing of Consistency and of Intelligence | Synchronous communication makes it a bit easier to create consistent state across services from a client’s perspective. Intelligence from the consistent state are derived eventually—that is, eventual intelligence and continuous consistency | Events, being asynchronous, mean that different services become consistent with one another only in eventuality: There is no control over the timeliness of the process of event propagation. |
EDA is not a superior pattern over SOA. Both patterns have their merits and characteristics. It's important to realise when to chose one pattern over the other. Jerry Mathew in aforementioned article distills the following discriminants.
If the priority lies on maintaining state first, and then derive insights SOA is a perfect pattern to apply. In case of of continuous intelligence-responses EDA is a better fit.
In Microservices patterns: synchronous vs asynchronous communication - greeeg.com the author states:
Use synchronous communication if:
The operation is a simple query which does not change any state The operation result is needed to move forward in the current process The operation can fail and does not require a complex retry mechanism The operation needs to be synchronous
Use asynchronous communication if: The operation involves multiple services reacting to it
The operation must be performed while allowing failures & retries
The operation takes a lot of time